The Usual Suspects is happy to announce the release of our latest emulation, OsTIrus. OsTIrus is a plugin which supports emulation of the Access Virus TI line of synthesizers. Like our previous emulators Osirus and Vavra, OsTIrus runs inside your DAW directly and can be controlled like any normal softsynth. Past users of the Virus TI will be able to relive their experience with this legendary synthesizer while having all the modern comforts of software plugins.
OsTIrus supports loading multiple instances, multitimbrality, enhanced voice allocation, and can be used as an FX plugin for other tracks in your DAW. Unlike other software versions of hardware inspired plugins, OsTIrus is already capable of producing bit-accurate output of the original by emulating the digital processors at the heart of the Virus TI.
OsTIrus is available for download from our website at the following link:
We have discovered that the Virus TI DSP code can run with sample rates that are higher than what the hardware is capable of. We can use this to our advantage in OsTIrus because we are not limited to the hardware.
The hardware only supports up to two different sample rates:
44100 Hz (TI, TI2, Snow)
48000 Hz (TI, TI2)
However, the DSP code can handle the following sample rates, too:
32000 Hz
64000 Hz
88200 Hz
96000 Hz
Adjusting the Sample Rate in OsTIrus
The following is implemented since OsTIrus version 1.3.8:
By default, OsTIrus uses either 44100 Hz or 48000 Hz, it automatically selects the best sample rate to match the host/DAW sample rate.
However, the sample rate can be overwritten manually in the advanced settings context menu:
Impact
Note that the DSPs run at the same clock rate no matter what sample rate is selected, running at a higher sample rate will reduce the maximum voice count.
Furthermore, we cannot say how much development has gone into this never-finished-feature. That a higher sample rate increases the quality of the generated audio is not guaranteed and is up to you to decide if its worth it.
Technical Details
If the sample rate is modified in global settings, the external frequency at which various hardware runs is modified, too.
The external clock (EXTAL) that is fed to the DSPs is either ~11,29 MHz (44100 Hz * 256) or ~12,288 MHz (48000 Hz * 256). The DACs (Digital to Analog audio converters) are fed by the same clock and USB is too.
Running at a higher clock than 48 KHz would be too much for the USB interface, maybe that is why they limited it to a maximum of 48 KHz.
The DSP clock is 133 MHz by default and is dynamically overclocked based on patch complexity. If the external clock is changed, the DSP PCTL register is modified accordingly to set the DSP to 133 MHz again.
By using a logic analyzer, we figured out that the microcontroller sends two words to the DSPs to inform about the new sample rate:
You can imagine that it was very tempting to see what the DSP does if we send something higher than $1 😊
It turned out that the DSPs react to higher numbers by adjusting the pitch, LFO rates etc. to match even higher sample rates. 👍
For higher sample rates, the DSP does not seem to expect a different EXTAL clock and still adjusts the DSP to 133 MHz. That is why we expect that higher sample rates result in less voices, but feel free to try! Also, you might be able to reach a higher voice count if you overclock the DSP.
Future emulator releases with versions 1.3.4 or higher allow to modify the DSP clock. This setting is part of a new section called Advanced Settings.
This setting directly affects host CPU utilization. If you run the DSP only at 50% of the desired speed, your host CPU utilization will be 50% of the default, if you run it at 200% the host CPU will use 200% of the default and so on.
The advantage of this is that users with older CPUs can lower the DSP clock to use the emulator without audio dropouts. Users with very fast CPUs can overclock the DSP to use more voices.
Impact
Even though Osirus, OsTIrus and Vavra have a fixed maximum voice count, they all use dynamic voice stealing depending on patch complexity. For example, while Vavra has 25 voices max, you might be able to use less voices if the patch is very complex.
Dynamic voice stealing works by measuring the time the DSP has spent to process voices VS the fixed audio clock at which samples need to be transferred. If the DSP is running out of time, voices are cut to prevent audio drop outs.
This is where DSP underclocking / overclocking can help.
If the DSP is running at a lower frequency, the host CPU utilization is reduced, but less voices will be available.
On the other hand, if the DSP is running at a higher frequency, the total maximum voices can be used even with more complex patches. This does not mean that you can use more than 25 voices on Vavra, but you can use all 25 voices even on more complex patches. The same applies to Osirus and OsTIrus.
Version 1.3 of Osirus introduces a new feature called the Patch Manager (included with all emulations in future builds)
The Patch Manager is a completely new feature that replaces the previous Preset Browser. While the old system didn’t provide much more than browsing files with patches on disk, the Preset Manager uses an approach away from banks towards categories, tags and favourites to provide a modern user experience.
Furthermore, more file formats are now supported:
.syx/.mid Virus A/B/C/TI/TI2 preset dumps
.fxb/.vstpreset Presets saved by DAW from Virus Powercore and Virus TI Control Software
.mid Virus A/B/C OS Update files that include Factory Presets
.syx/.mid microQ/Q preset dumps
.syx/.mid microWAVE 2/XT preset dumps
The Patch Manager is part of the plugin itself and can be accessed by clicking Presets (Osirus), Patches (Vavra) or Browser (OsTIrus) depending on which emulator you are using.
Patches are provided by various sources called Data Sources, the ROM patches are automatically added to Factory where applicable (not for Waldorf synths due to the way they work in the hardware). Additional patches from disk can be added via right click on the Data Sources node. Select a file or even a whole folder to add it to the database.
It is highly recommended to keep your patches and banks located on disk separately from your plugin folder locations to avoid operating system permissions issues that may cause incorrect operation of the Patch Manager, and also to prevent slowness of startup performance in the case of Vavra.
In this database, patches can be reorganized into Categories, Tags and Favourites. You can create your own Categories, Tags and Favorites by right-clicking on the appropriate heading and selecting Add.
As categories may not always be correct, you can modify categories and tags for all patches that have been added to the database, you can even modify the the categories of ROM patches if you like.
Categories, tags and favourites can be colored and are displayed accordingly in any search result.
Text-based filtering allows to filter data sources, tags and patch lists.
Categories, tags and favourites can be added via drag & drop, just drag patches onto an existing category/tag/favourite container to add the patch. Removal is done via drag & drop too, just hold shift while dragging.
It is important to note that the patches themselves are not modified, instead, all changes are kept in separate files to leave your imported banks untouched.
User Banks allow you to save your custom patches, you can create an arbitrary amount of User Banks and add your patches by dragging the patch name from the parts list onto a User Bank. Create a User Bank by right-clicking on User and select Create to add a User Bank.
If you want to export a User Bank to use your patches with a hardware synth, right click to show a context menu, you can export your patches as .syx or .mid.
If you intend to export a User Bank to the actual hardware synth, consider to limit the number of patches in that bank to fit within the size of the hardware bank. Any patches beyond the limit of the hardware bank will be ignored by the hardware synth when importing from this file.
Technical Information
The Patch Manager consists of a database that keeps track of all patches that have been added to it. Furthermore, each patch can have modifications. Modifications can be either the addition or the removal of tags or a name change (User Banks only at the moment).
Technically, Categories, Tags and Favourites are all tags, but the tag type is different. Additional tag types are the Virus Model and the Virus Features, internally (and in the json files) these are CustomA and CustomB because they vary from device to device.
Storage Format:
The database keeps track of which data sources have been added, it is stored at:
In this case, The category “Favourite 3” has been removed from the first patch of that bank.
Backup Strategy
All tags that have been added to/removed from patches that you added as data source are saved next to the data source itself, i.e. if you backup your presets, be sure to copy the json files that are next to them too and you’re done.
User banks are stored in the Application Support/Userdata Roaming folder (see above), if you want to backup those you can copy the whole folder or copy the individual .syx files along with the .json files that have the same name.
If you accidentally removed a user bank from the DB, you can create a “new” user bank with the same name. If the .syx file still exists on disk in the user data folder (which is likely because they are never physically deleted from disk), it will be loaded and used, i.e. the Create becomes an Add.
We recently made a lot of progress with Vavra, the Waldorf microQ emulator, time for an update.
The GUI contains two skins, one is closely designed to match the device and is intended to be used to preserve the device as it was in a digital form. The second skin is a fully fledged editor to allow easy editing of patches.
Below are two videos of it in action.
The plugin is in alpha stage at the moment. It cannot store the state of the project yet and misses the Drum and Multi modes. It is tested exclusively by donators.
Having said that, this video shows the current state of the Waldorf microQ emulator in action.
As we do not only emulate the DSP, but the full machine this time, the test program is a bit different. It displays the full microQ in a terminal GUI and can be fully operated via keyboard. The test program runs in realtime and features Midi in/out and Audio out.
The emulator is run on an i7 4790k (~2014), the CPU usage is shown at the bottom of the video.
The two videos below have been recorded with an early alpha version of the TI emulator.
Further optimizations on the DSP emulation side made it possible that these videos were recorded in realtime on a rather old i7 4790k CPU (~2014, 4 cores, 8 threads), CPU usage per thread can be seen in the first video. As expected, while the TI runs in Single Mode, only the first DSP is used, that is why the thread load for the first DSP is higher than for the second one.
The second video showcases the TI as FX unit by routing a song to the inputs.
As there were some questions regarding this, a general explanation about latency and further insights about the new setting in Osirus 1.2.19 (currently in beta testing phase)
Latency setting in Osirus 1.2.19
Osirus always processes the DSP in a separate thread. There are multiple reasons for this, but one advantage is that the DSP can continue doing work even if the DAW does not ask us to process anything. This results in a higher throughput.
If you imagine how a DAW processes plugins, it looks a bit like this.
Of course, it is much more complex, especially if a DAW uses multiple threads to process plugins. But in general, any DAW needs to process our plugin first and then any FX that we have chained after. The consequence is that we are unable to continue doing DSP processing work as long as the DAW doesn’t allow us to do so. This is an issue if the used host CPU is slow and cannot finish processing the required amount of data in the timeframe that the DAW provides to us.
If we add one audio block of latency though, we can change this behavior. We can start a separate thread that does DSP processing which will continue to run even if the DAW doesn’t ask for a new block of audio data yet.
In Osirus, we do exactly that. We tell the DSP thread when its time to process a block of audio data and at the same time, we retrieve the previous work that the DSP thread must have finished processing by now.
While this behavior has the advantage of allowing slower CPUs to use the plugin, the disadvantage of this is one block of latency and also that the DAW CPU meter does not tell you the amount of work that is done in the DSP thread.
The DAW CPU meter will calculate the CPU usage based on how long it took the plugin to finish processing the submitted audio block. As we do not really do any work in the DAW audio thread, the DAW CPU meter displays a surprisingly low number as it is not aware that we do the heavy lifting in a separate thread that runs independently.
However, if the DSP thread does not finish in time and the audio thread needs to enter blocking state because it has to wait for the DSP thread to finish, the DAW CPU meter instantly jumps to 100% because the DSP thread was too slow. This is why many users with slower CPUs report “CPU spikes”, even though it doesn’t really spike, its just that your CPU is very close to being maxed out and depending on the voice count and other circumstances, may not be fast enough.
The new latency setting
The additional latency can now be adjusted. Please note that this setting is multiplied with the audio block size. The default setting is 1, which represents the old behavior as explained above.
Users with slower CPUs may want to increase this value, the DSP thread will have even more time to finish work, but the latency will increase.
Users with fast CPUs may want to set it to zero, in which case the DAW audio thread will wait for the DSP to finish its work, eliminating the additional latency entirely. A side effect of this is that the DAW will report the proper CPU usage, so if you’re unsure if the “spikes” are real, set it to zero to see what the real CPU load is.
Device Latency
Note that all of the above is independent from the device latency, i.e. the latency that is introduced by the emulated ROM itself. For example, a Virus B&C has about 370 samples of midi-to-output latency at 46875 Hz with a jitter +/- 60 samples. This latency is converted to the DAW samplerate and is always reported on top of the latency that the plugin introduces depending on the latency setting above.
We have updated our Technical Info page with some insights about how the multi-DSP setup on the Virus TI works. Also, it has a useful tip for hardware TI owners to maximize voice count in Multi Mode / Sequencer Mode, enjoy! 👍
As questions are imminent, a statement regarding Virus TI emulation:
Virus TI emulation development is done in a private fork of the public project. We do this with the goal to have the whole line of Virus synthesizers emulated, to improve the accuracy and feature set of the emulation in general, to learn about the internal architecture as a preparation for other future synthesizers and of course, because it is a lot of fun!
However, currently we do not have plans to release a version of the emulator that supports the Virus TI, TI2 or Snow as this generation of synthesizers is still being sold. We do not want to negatively impact current or future sales of Kemper GmbH or affiliates, it is exactly the opposite. We appreciate the achievements of Access Music / Kemper and created Virus B & C emulators as an appreciation and to preserve these great synthesizers in a digital form.
We are very happy to announce that we have reached a state where the emulator can be used without any external editors. The emulator now includes its own user interface for Virus B & Virus C!
The UI has been contributed by multiple external developers, we would like to thank everyone being involved in this! 👍
Furthermore, the emulation code of the DSP 56300 has been optimized, better performance results in speed improvements between 10% and 20% to make the emulation usable even on older CPUs.
DSP56300 Emulation Blog 